How to Display Object Modifications of Suspect Links of Baselined Module

Mathias Mamsch - Tue Dec 08 20:11:11 EST 2009

Suspect links work as you probably know by comparing the "Suspicion Cleared Forwards"/"Suspicion Cleared Backwards" date on the link (i.e. the date when the suspicions were last cleared) with the last modification date of the object. What is not so well known is, that you can get the exact time an object was last modified by calling the 'Date lastModifiedTime (Object)' perm. This perm can return null for data from earlier versions, so if this perm will return null you have to take the "last modified on" attribute, which will only give you the day.

Once you know about this function you can easily implement your suspect links functionality in combination with reading the data from earlier baselines. The following code shows you how to open the baselines and scan an object in all baselines for history entries before a special date. Using the lastModifiedTime perm in combination with below and the link code it should get you the results you wanted.

Best regards, Mathias
 

Baseline b 
Module m
 
Date modificationDate = "11/19/09 10:00:00"
Object searchObj = current
 
Skip sk = create() 
Date D
 
int count = 0
// Use a skip list to sort the baselines in reverse order
for b in current Module do put (sk, count--, b); 
 
// put a dummy item to the skip list, so we can use the same
// loop for current module and baselines. Put it after the last one
put (sk, count , null Baseline) 
 
// iterate through the baselines
for b in sk do {
    if (!null b) {
                // check if the baseline was done before the modificationd date
                // -> no interesting history could be in there
                D = dateAndTime dateOf b
                if (D < modificationDate) break
 
                // load the baseline
                print "Scanning baseline: " (major b) "." (minor b) (suffix b) "  -->  " D "\n"
                m = load(b, false) 
        } else { 
                // load the current module
                print "Scanning current module ...\n"
                m = current Module
        }
 
        // find the object in the baseline by absolute number
        int searchNr = searchObj."Absolute Number"
 
        // first search the object using the fast object function
        // won't work for non visible objects, use a 'for obj in entire m' 
        // loop to maybe find the object if it is null
        Object targetObj = object(searchNr, m) 
 
        // if the object did not exist in the baseline then do nothing  
        if (null targetObj) { print "Object not found!"; halt }
 
        History h
        // scan the object history in the baseline
        for h in targetObj do {
                Date historyDate = h.date
                if (historyDate > modificationDate) {
                        print "Scanning history entry: " h.date "\n"
                        if (h.type == modifyObject) {
                                print h.oldValue "->" h.newValue "\n"
                        }
                }
        }
 
}

SystemAdmin - Wed Jun 09 16:06:00 EDT 2010
Mathias and all,
I've used the above code as a basis for finding objects within created baselines. One problem I'm finding however is that the module I am using is very old, and has many baselines. My system will long run out of resources before it can scan all the baselines and return the results I'm looking for. I suspect that is because I am opening multiple modules/baselines here, but I'm not certain. After opening 10 modules from baselines, per the code, I'm well over 1.5G of memory allocated to DOORS - even if I halt the script, deleting the skip list and closing the current module, I can't regain the system resources.

Is there any way to free up the resources that are being taxed somehow? While I understand DXL to a degree, garbage collection within DOORS is definitely not my strong suit. Any help would be appreciated!

Thanks,
Mike

Mathias Mamsch - Tue Dec 08 20:11:11 EST 2009

Suspect links work as you probably know by comparing the "Suspicion Cleared Forwards"/"Suspicion Cleared Backwards" date on the link (i.e. the date when the suspicions were last cleared) with the last modification date of the object. What is not so well known is, that you can get the exact time an object was last modified by calling the 'Date lastModifiedTime (Object)' perm. This perm can return null for data from earlier versions, so if this perm will return null you have to take the "last modified on" attribute, which will only give you the day.

Once you know about this function you can easily implement your suspect links functionality in combination with reading the data from earlier baselines. The following code shows you how to open the baselines and scan an object in all baselines for history entries before a special date. Using the lastModifiedTime perm in combination with below and the link code it should get you the results you wanted.

Best regards, Mathias
 

Baseline b 
Module m
 
Date modificationDate = "11/19/09 10:00:00"
Object searchObj = current
 
Skip sk = create() 
Date D
 
int count = 0
// Use a skip list to sort the baselines in reverse order
for b in current Module do put (sk, count--, b); 
 
// put a dummy item to the skip list, so we can use the same
// loop for current module and baselines. Put it after the last one
put (sk, count , null Baseline) 
 
// iterate through the baselines
for b in sk do {
    if (!null b) {
                // check if the baseline was done before the modificationd date
                // -> no interesting history could be in there
                D = dateAndTime dateOf b
                if (D < modificationDate) break
 
                // load the baseline
                print "Scanning baseline: " (major b) "." (minor b) (suffix b) "  -->  " D "\n"
                m = load(b, false) 
        } else { 
                // load the current module
                print "Scanning current module ...\n"
                m = current Module
        }
 
        // find the object in the baseline by absolute number
        int searchNr = searchObj."Absolute Number"
 
        // first search the object using the fast object function
        // won't work for non visible objects, use a 'for obj in entire m' 
        // loop to maybe find the object if it is null
        Object targetObj = object(searchNr, m) 
 
        // if the object did not exist in the baseline then do nothing  
        if (null targetObj) { print "Object not found!"; halt }
 
        History h
        // scan the object history in the baseline
        for h in targetObj do {
                Date historyDate = h.date
                if (historyDate > modificationDate) {
                        print "Scanning history entry: " h.date "\n"
                        if (h.type == modifyObject) {
                                print h.oldValue "->" h.newValue "\n"
                        }
                }
        }
 
}

a_vestlin - Thu Jun 10 02:40:10 EDT 2010
Hi,

Suspect Links should be defined as Mattias states, but I believe it works in a slightly different way. In DOORS 8.1 changes to any link attribute which changes 'change date' (use bool lastModifiedTime(Link l) to find out) will clear the suspiciousness of the link, both as inlink and outlink. This suggests it is really a comparison of the change date of the object (in the other end) and the link which is used to determine if a link is suspect. The effect of this is that clearing a suspect link for a certain direction also will clear the other direction.

In DOORS 9.2 this behavior is still the same for suspect outlinks but not for the inlinks. Suspect Inlinks are really using the 'Suspicion Cleared Backwards' attribute.

/Anders

Mathias Mamsch - Thu Jun 10 03:14:34 EDT 2010
You are right there is also a check on the "last modified time" of the link, but ONLY if the attributes "SUSPICION LAST CLEARED XY" do not exist OR are empty!

The "Suspicion Last Cleared" Value of the link is therefore the value of those attributes if they have one, otherwise it is the last modified time of the link (which is usually the link creation date. Who uses link attributes anyway :-)). This "Suspicion Last Cleared" value is compared to the "last modified time" of the target object (out link) or source object (in link).

I am pretty sure that this is how the suspicion is determined in DOORS 8.1 too, in DOORS 8.2 it is definitly like this. I would bet that it is the same in DOORS 9 too.

Regards, Mathias

Mathias Mamsch - Wed Jun 09 17:26:17 EDT 2010
This sounds like a memory leak to me ... Normally you can open and close modules without leaving memory garbage ... Are you maybe using Buffers to parse your module content and forgot some cleanup? Maybe it would be best if you post the code. Memory leaks are hard to track down most of the time.

You should not have all baselines opened at the same time if you don't need to. There is no such thing like "Automatic Garbage Collection" in DXL you need to take care of the ressources you allocate yourself.

Regards, Mathias

SystemAdmin - Thu Jun 10 09:20:11 EDT 2010

Mathias,

I actually started with the code you posted above line for line, and have only been trying to reduce the memory footprint from there before I modify it further. If we start with the code above, my machine will lock up on a module with 59 major baselines, and a handful of minor baselines. The module is around 16,000 objects large. If I add a simple counter in the do loop that halts execution after 10 cycles, and clearing out the skip list (as per below), memory for the DOORS application hovers around 1.2G and must be closed out to reclaim the resources. If I attempt to let it cycle the entire script through all baselines, the script cannot finish.
 

if (!null b) {
xCount += 1
if(xCount == 10) {
delete(sk)
halt
}
}

While I attempted to switch all string concatenation to buffers and subsequent deletions, the memory issue was not resolved, so I scrapped that code.

Thank you for your attention,
Mike

Mathias Mamsch - Thu Jun 10 14:57:49 EDT 2010
That must be a hell of a module, that you have there :-)

I guess a 16000 object module (depending on the contents) can take its 120MB in memory. If you open 10 baselines of it, you will have 1,2GB - no problem to believe that.

How much memory does DOORS consume before and after you open that module manually from the database explorer? If we are talking about a module that large you need better code than what I posted. What exactly are you trying to accomplish? Is it feasible to just close each baseline after scanning it? Or do you need to access the information from the baselines later? If we don't have a memory leak here, then I guess the key would be to read the neccessary information from all the baselines and store them somewhere (in memory, a file or somewhere persistent), close the baselines and use the stored information instead for whatever purpose you need it for.

Can you give some details on what your script is supposed to do?

Regards, Mathias